1. Field of the Invention
This disclosure relates to interrupts within a computer system and, more particularly, to serially scanning interrupt signals and avoiding associated spurious interrupts in a computer system
2. Description of the Related Art
A typical computer system contains at least one interrupt service provider, usually a central processing unit (CPU), and a number of input/output (I/O) devices peripheral to the CPU(s). These I/O devices commonly include hard disk drives, optical disk drives, video adapters, parallel ports, serial ports, and other similar I/O type devices. An I/O device may need to alert the CPU(s) or request service when it completes a task or has a status change, such as finishing a data transfer, completing an operation, receiving data, or the occurrence of an error condition.
The typical mechanism for an I/O device to request service from the CPU(s) involves an interrupt request. An interrupt request is generally a hardware signal sent from the requesting device to an interrupt controller to notify a CPU that the I/O device requires service. Other system devices such as timers, direct memory access (DMA) controllers, and other processors may generate interrupt request signals.
One advantage of using interrupts over other techniques, such as polling, is that the CPU is free to perform other operations between interrupts. When a CPU receives an interrupt request, it stops executing the current instruction routine, saves its state, and jumps to an interrupt service routine. The interrupt service routine includes instructions specific to the device requesting the interrupt so that the CPU can respond to the device condition or status change that instigated the interrupt request. When the interrupt service routine is completed, the CPU restores its state and returns to its location prior to the interrupt.
Generally speaking, in a typical system, a programmable interrupt controller receives the interrupt request signals from the various system devices and organizes the requests to be sent to the CPU(s). A typical interrupt controller has a separate input conductor for each interrupt request signal. In PCs, the so called "legacy interrupts" are usually supported in an interrupt controller. Two cascaded 8259-type interrupt controllers may receive the "legacy" interrupt request signals IRQ[15:3, 1]. Historically, IRQ2 has been used for cascading the 8259 interrupt controllers and IRQ0 is often implemented as an internal timer interrupt. In more modern systems, the interrupt controller may receive additional interrupts, such as interrupts from a peripheral component interconnect (PCI) bus or system management interrupts. These additional interrupts add additional input conductors to the interrupt controller. In some cases, a custom interrupt controller may have to be designed to handle the additional interrupts. Usually a larger package size will be required for the additional input conductors. To avoid the need for additional input conductors, interrupt requests may share a single input conductor by wired-OR sharing. However, with wired-OR sharing, the interrupt controller cannot determine the source of the interrupt request. Typically, all devices sharing an interrupt input conductor must be polled to determine which device requested the interrupt. Polling may have a detrimental effect on performance.